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Abstract 


In most RTP-based multicast applications, the RTP source sends inter- 
related data. Due to this interdependency, randomly joining RTP 
receivers usually cannot start consuming the multicast data right 
after they join the session. Thus, they often experience a random 
acquisition delay. An RTP receiver can use one or more different 
approaches to achieve rapid acquisition. Yet, due to various 
factors, performance of the rapid acquisition methods usually varies. 
Furthermore, in some cases, the RTP receiver can do a simple 
multicast join (in other cases, it is compelled to do so). For 
quality reporting, monitoring, and diagnostic purposes, it is 
important to collect detailed information from the RTP receivers 
about their acquisition and presentation experiences. This document 
addresses this issue by defining a new report block type, called the 
Multicast Acquisition (MA) report block, within the framework of RTP 
Control Protocol (RTCP) Extended Reports (XRs) (RFC 3611). This 
document also defines the necessary signaling of the new MA report 
block type in the Session Description Protocol (SDP). 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6332. 
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Copyright (c) 2011 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 


(http://trustee.ietf.org/license-info) 


publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with 


to this document. 


in effect on the date of 
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Code Components extracted from this document must 


include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Les 


Introduction 


The RTP Control Protocol (RTCP) is the out-of-band control protocol 
for applications that use the Real-time Transport Protocol (RTP) for 
media transport [RFC3550]. In addition to providing minimal control 
functionality to RTP entities, RTCP also enables a basic-level 
monitoring of RTP sessions via sender and receiver reports. More 
statistically detailed monitoring as well as application-specific 
monitoring are usually achieved through the RICP Extended Reports 
(XRs) [RFC3611]. 


In most RTP-based multicast applications such as the ones carrying 
video content, the RTP source sends inter-related data. 
Consequently, the RTP application may not be able to decode and 
present the data in an RTP packet before decoding the data in one or 
more earlier RTP packets and/or before acquiring some Reference 
Information about the content itself. Thus, RTP receivers that are 
randomly joining a multicast session often experience a random 


acquisition delay. In order to reduce this delay, [RFC6285] proposes 
an approach where an auxiliary unicast RTP session is established 
between a retransmission server and the joining RTP receiver. Over 


this unicast RTP session, the retransmission server provides the 
Reference Information, which is all the information the RTP receiver 
needs to rapidly acquire the multicast stream. This method is 
referred to as the Rapid Acquisition of Multicast RTP Sessions 
(RAMS). However, depending on the variability in the Source 
Filtering Group Management Protocol (SFGMP) processing times, the 
availability of network resources for rapid acquisition, and the 
nature of the RTP data, not all RTP receivers can acquire the 
multicast stream in the same amount of time. The performance of 
rapid acquisition may vary not only for different RTP receivers but 
also over time. 


To increase the visibility of the multicast service provider in its 
network, to diagnose slow multicast acquisition issues, and to 
collect the acquisition experiences of the RTP receivers, this 
document defines a new report block type, which is called the 
Multicast Acquisition (MA) report block, within the framework of RTCP 
XR. RTP receivers that use the method described in [RFC6285] may use 
this report every time they join a new multicast RTP session. RTP 
receivers that use a different method for rapid acquisition or those 
that do not use any method but rather do a simple multicast join may 
also use this report. This way, the multicast service provider can 
quantitatively compare the improvements achieved by different 
methods. 
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24 


Requirements Notation 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
[RFC2119]. 


Definitions 


This document uses the acronyms and definitions from Section 3 of 
[RFC6285]. 


Multicast Acquisition (MA) Report Block 


This section defines the format of the MA report block. The base 
report is payload independent. An extension mechanism is provided 
where further optional payload-independent and payload-specific 
information can be included in the report as desired. 


The OPTIONAL extensions that are defined in this document are 
primarily developed for the method presented in [RFC6285]. Other 
methods that provide rapid acquisition can define their own 
extensions to be used in the MA report block. 


The packet format for the RTCP XR is defined in Section 2 of 
[RFC3611]. Each XR packet has a fixed-length field for version, 
padding, reserved bits, payload type (PT), length, synchronization 
source (SSRC) of packet sender as well as a variable-length field for 
report blocks. In the XR packets, the PT field is set to XR (207). 


It is better to send the MA report block after all the necessary 
information is collected and computed. Partial reporting is 
generally not useful as it cannot give the full picture of the 
multicast acquisition, and it causes additional complexity in terms 
of report block matching and correlation. The MA report block is 
only sent as a part of an RTCP compound packet, and it is sent in the 
primary multicast session. 


The need for reliability of the MA report block is not any greater 
than other report blocks or types. If desired, the report block 
could be repeated for redundancy purposes while respecting the RTCP 
scheduling algorithms. 


Following the rules specified in [RFC3550], all integer fields in the 
base report and extensions defined below are carried in network-byte 
order, that is, most significant byte (octet) first, also known as 
big-endian. Unless otherwise stated, numeric constants are in 
decimal (base 10). 
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4.1. Base Report 
The base report format is shown in Figure 1. 


0 1 2 3 
01234567890123456789012345678901 
+44 4444444444444 444444444444 
| BT=11 | MA Method | Block Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +H 

| SSRC of the Primary Multicast Stream 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ++ 
| Status | Rsvd. | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 


Figure 1: Base Report Format for the MA Report Block 


o BT (8 bits): Field that denotes the type for this block format. 
The MA report block is identified by the constant 11. 


o MA Method (8 bits): Field that denotes the type of the MA method 
(e.g., simple join, RAMS, etc.). See Section 7.3 for the values 
registered with IANA. 


o Block Length (16 bits): The length of this report block, including 
the header, in 32-bit words minus one. 


o SSRC of the Primary Multicast Stream (32 bits): Field that denotes 
the SSRC of the primary multicast stream. 


o Status (16 bits): Field that denotes the status code for the MA 
operation. 


This document defines several status codes and registers them with 
IANA in Section 7.5. If a new vendor-neutral status code will be 
defined, it MUST be registered with IANA according to the 
guidelines specified in Section 7.5. If the new status code is 
intended to be used privately by a vendor, there is no need for 
IANA management. Section 4.2.2 defines how a vendor defines and 
uses private extensions to convey its messages. 


To indicate use of a private extension, the RTP receiver MUST set 
the Status field to zero. A private extension MUST NOT be used in 
an XR unless the RTP receiver knows from out-of-band methods that 
the entity that will receive and process the XR understands the 
private extension. 


o Rsvd. (16 bits): The RTP receiver MUST set this field to zero. 
The recipient MUST ignore this field when received. 
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If the multicast join was successful, meaning that at least one 
multicast packet was received, some additional information MUST be 
appended to the base report as described in Section 4.2.1. 


A Me by Status Code Rules for New MA Methods 


Different MA methods usually use different status codes, although 

some status codes (e.g., a code indicating that multicast join has 
failed) can be common among multiple MA methods. The status code 

reported in the base report MUST always be within the scope of the 
particular MA method specified in the MA Method field. 


In certain MA methods, the RTP receiver can generate a status code 
for its multicast acquisition attempt or can be told by another 
network element or RIP endpoint what the current status is via a 
response code. In such cases, the RTP receiver MAY report the value 
of the received response code as its status code if the response code 
has a higher priority. Each MA method needs to outline the rules 
pertaining to its response and status codes so that RTP receiver 
implementations can determine what to report in any given scenario. 


4.1.2. Status Code Rules for the RAMS Method 


In this section, we provide the status code rules for the RAMS method 
described in [RFC6285]. 


Section 11.6 of [RFC6285] defines several response codes. The 1xx- 
and 2xx-level response codes are informational and success response 
codes, respectively. If the RTP receiver receives a 1xx- or 2xx- 
level response code, then the RTP receiver MUST use one of the 1xxx- 
level status codes defined in Section 7.5 of this document. If the 
RTP receiver receives a 4xx- or 5xx-level response code (indicating 
receiver-side and server-side errors, respectively), then the RTP 
receiver MUST use the response code as its status code. In other 
words, the 4xx- and 5xx-level response codes have a higher priority 
than the 1xxx-level status codes. 


4.2. Extensions 


To improve the reporting scope, it might be desirable to define new 
fields in the MA report block. Such fields are to be encoded as TLV 
elements as described below and sketched in Figure 2: 


o Type: A single-octet identifier that defines the type of the 
parameter represented in this TLV element. 
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o Length: A two-octet field that indicates the length (in octets) of 
the TLV element excluding the Type and Length fields and the 8-bit 
Reserved field between them. Note that this length does not 
include any padding that is needed for alignment. 


o Value: Variable-size set of octets that contains the specific 
value for the parameter. 


In the extensions, the Reserved field MUST be set to zero and ignored 


on reception. If a TLV element does not fall on a 32-bit boundary, 
the last word MUST be padded to the boundary using further bits set 
to zero. 


In the MA report block, the RIP receiver MUST place any vendor- 
neutral or private extension after the base report. 


0 1 2 3 

0. 2-3 4.5.08 OT 2B A S G EI 0 232567050: 
44-44-4444 444444444 44444444444 
| Type | Reserved | Length 
4444444444444 4444444444444 
: Value : 
44-44-4444 444444444444 444444444 


Figure 2: Structure of a TLV Element 
4.2.1. Vendor-Neutral Extensions 
If the goal in defining new TLV elements is to extend the report 


block in a vendor-neutral manner, they need to be registered with 
IANA according to the guidelines provided in Section 7.4. 


This document defines several vendor-neutral extensions. First, we 
present the TLV elements that can be used by any RTP-based multicast 
application. 


o RTP Seqnum of the First Multicast Packet (16 bits): TLV element 
that specifies the RTP sequence number of the first multicast 
packet received for the primary multicast stream. If the 
multicast join was successful, this element MUST be included. If 
no multicast packet has been received, this element MUST NOT exist 
in the report block. 


Type: 1 
Oo SFGMP Join Time (32 bits): TLV element that denotes the greater of 


zero or the time difference (in ms) between the instant the SFGMP 
Join message was sent and the instant the first packet was 


Begen & Friedrich Standards Track [Page 7] 


RFC 6332 


received in 
successful, 


MA Report Block Type for RTCP XR July 2011 


the multicast session. If the multicast join was 
this element MUST be included. If no multicast packet 


has been received, this element MUST NOT exist in the report 


block. 
Type: 2 


Application 
TLV element 
instant the 
session and 


primary multicast stream. 


Request-to-Multicast Delta Time (32 bits): OPTIONAL 
that denotes the time difference (in ms) between the 
application became aware it would join a new multicast 
the instant the first RIP packet was received from the 
If no such packet has been received, 


this element MUST NOT exist in the report block. 


Type: 3 


Application 
TLV element 
instant the 
session and 


receiver cannot successfully present the media, 


Request-to-Presentation Delta Time (32 bits): OPTIONAL 
that denotes the time difference (in ms) between the 
application became aware it would join a new multicast 
the instant the media was first presented. If the RTP 
this element MUST 


NOT exist in the report block. 


Type: 4 


We next present the TLV elements that can be used when the RTP 
receiver supports and uses the RAMS method described in [RFC6285]. 


However, 
request, 
block. 


if the RTP receiver does not send a rapid acquisition 
the following TLV elements MUST NOT exist in the MA report 
Some elements may or may not exist depending on whether or 


not the RTP receiver receives any packet from the unicast burst 


and/or the primary multicast stream. 


(0) 


Application 
TLV element 
instant the 
acquisition 


These are explained below. 


Request-to-RAMS Request Delta Time (32 bits): OPTIONAL 
that denotes the time difference (in ms) between the 
application became aware it would request a rapid 

and the instant the rapid acquisition request was 


actually sent by the application. 


Type: 11 
RAMS Request-to-RAMS Information Delta Time (32 bits): OPTIONAL 
TLV element that denotes the time difference (in ms) between the 


instant the 


Begen & Friedrich 


rapid acquisition request was sent and the instant the 
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first RAMS Information message was received in the unicast 
session. If no such message has been received, this element MUST 
NOT exist in the report block. 


Type: 12 
o RAMS Request-to-Burst Delta Time (32 bits): OPTIONAL TLV element 


that denotes the time difference (in ms) between the instant the 
rapid acquisition request was sent and the instant the first burst 


packet was received in the unicast session. If no burst packet 
has been received, this element MUST NOT exist in the report 
block. 

Type: 13 


o RAMS Request-to-Multicast Delta Time (32 bits): OPTIONAL TLV 
element that denotes the time difference (in ms) between the 
instant the rapid acquisition request was sent and the instant the 
first RTP packet was received from the primary multicast stream. 
If no such packet has been received, this element MUST NOT exist 
in the report block. 


Type: 14 


o RAMS Request-to-Burst-Completion Delta Time (32 bits): OPTIONAL 
TLV element that denotes the time difference (in ms) between the 
instant the rapid acquisition request was sent and the instant the 
last burst packet was received in the unicast session. If no 
burst packet has been received, this element MUST NOT exist in the 
report block. 


Type: 15 


o Number of Duplicate Packets (32 bits): OPTIONAL TLV element that 
denotes the number of duplicate packets due to receiving the same 


packet in both unicast and primary multicast RTP sessions. If no 
RTP packet has been received from the primary multicast stream, 
this element MUST NOT exist. If no burst packet has been received 
in the unicast session, the value of this element MUST be set to 
zero. 

Type: 16 


o Size of Burst-to-Multicast Gap (32 bits): OPTIONAL TLV element 
that denotes the greater of zero or the difference between the 
sequence number of the first multicast packet (received from the 
primary multicast stream) and the sequence number of the last 
burst packet minus 1 (considering the wrapping of the sequence 
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numbers). If no burst packet has been received in the unicast 
session or no RTP packet has been received from the primary 
multicast stream, this element MUST NOT exist in the report block. 


Type: 17 
4.2.2. Private Extensions 


It is desirable to allow vendors to use private extensions in TLV 
format. The range of [128-254] of TLV Types is reserved for private 
extensions. IANA management for these extensions is unnecessary; 
they are the responsibility of individual vendors. 


Implementations use the structure depicted in Figure 3 for private 
extensions. Here, the private enterprise numbers are used from 
http://www.iana.org. This will ensure the uniqueness of the private 
extensions and avoid any collision. 


0 1 2 3 
Od. 2 BAe 6. FP BQO. 8 2.3.4 5.67 89.0.2172 3: 4.6 8 Qe 
+44 44-44-4444 44-44-4444 4444444444444 + 

| Type | Reserved | Length 

+-4+-+-4- 444-4444 4444444444 44444444444 + 
| Enterprise Number | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
: Value : 
Foti titi 444-4444 44-44-4444 4444444444444 + 


Figure 3: Structure of a Private Extension 
5. Session Description Protocol Signaling 
A new unilateral parameter is defined for the MA report block to be 
used with the Session Description Protocol (SDP) [RFC4566]. In the 


following ABNF [RFC5234], xr-format is used as defined in [RFC3611]. 


xr-format =/ multicast-acq-ext 
multicast-acq-ext = "multicast-acq" 


Refer to Section 5.1 of [RFC3611] for a detailed description and the 
full syntax of the ’rtcp-xr’ attribute. 
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6. Security Considerations 


The security considerations of [RFC3611] apply in this document as 
well. 


The information contained in MA reports could be stolen as with any 
other RTCP reports if proper protection mechanism(s) are not in 
place. If desired, similar to other RTCP XRs, the MA reports MAY be 
protected by using Secure RTP (SRTP) and Secure RTP Control Protocol 
(SRTCP) [RFC3711]. 


Malicious sniffing or otherwise obtaining MA report blocks can reveal 
performance characteristics of the RIP service and underlying 
network. This information is mostly available to an observer with 
the ability to capture RTP and RTCP session traffic. The contents 
and value of any private extension need to be studied when 
considering the necessity to secure the MA reports since application- 
level performance data might be present that is not otherwise 
available to an attacker, as with the required fields and vendor- 
neutral extensions. 


Using the MA reports to provide feedback into the acquisition of the 
multicast streams can introduce possible additional security 
implications. If a forged or otherwise modified MA report is 
received for an earlier acquisition attempt, invalid data can be used 
as input in later rapid acquisition attempts. For example, 
incorrectly small SFGMP join times could cause the unicast burst to 
be too short, leading to gaps in sequence numbers in the approach 
discussed in [RFC6285]. Additionally, forged reports could give the 
appearance that rapid acquisition is performing correctly when it is 
in fact failing, or vice versa. While integrity protection can be 
achieved in different ways, we RECOMMEND the use of SRTCP [RFC3711]. 


7. (IANA Considerations 


The following contact information is provided for all registrations 
in this document: 


Ali Begen 
abegen@cisco.com 


7.1. RICP XR Block Type 


Type value 11 has been registered with IANA for the "Multicast 
Acquisition Report Block" in the RTCP XR Block Type Registry. 
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7.2. RTCP XR SDP Parameter 


The SDP [RFC4566] parameter /multicast-acq’ for the ’rtcp-xr’ 
attribute has been registered in the RTCP XR SDP Parameters Registry. 


7.3. Multicast Acquisition Method Registry 
A new IANA registry for the MA methods has been created. The 
registry is called the "Multicast Acquisition Method Registry". This 
registry is to be managed by IANA according to the Specification 


Required policy of [RFC5226]. 


The length of the MA Method field is a single octet, allowing 256 


values. The registry is initialized with the following entries: 
MA Method Description Reference 

0 Reserved [RFC6332] 

1: Simple join (No explicit method) [RFC6332] 

2 RAMS [RFC6285] 

3-254 Unassigned Specification Required 
255 Reserved [RFC6332] 


The MA Method values 0 and 255 are reserved for future use. 


Any registration for an unassigned value needs to contain the 
following information: 


o Contact information of the one doing the registration, including 
at least name, address, and email. 


o A detailed description of how the MA method works. 

7.4. Multicast Acquisition Report Block TLV Space Registry 
A new IANA TLV space registry for the MA report block extensions has 
been created. The registry is called the "Multicast Acquisition 
Report Block TLV Space Registry". This registry is to be managed by 
the IANA according to the Specification Required policy of [RFC5226]. 
The length of the Type field in the TLV elements is a single octet, 


allowing 256 values. The registry is initialized with the following 
entries: 
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Type Description Reference 
0 Reserved [RFC6332] 
1 RTP Seqnum of the First Multicast Packet [RFC6332] 
2 SFGMP Join Time [RFC6332] 
3 Application Request-to-Multicast Delta Time [RFC6332] 
4 Application Request-to-Presentation Delta Time [RFC6332] 
5-10 Unassigned Specification Required 
11 Application Request-to-RAMS Request Delta Time [RFC6332] 
12 RAMS Request-to-RAMS Information Delta Time [RFC6332] 
13 RAMS Request-to-Burst Delta Time [RFC6332] 
14 RAMS Request-to-Multicast Delta Time [RFC6332] 
1:5 RAMS Request-to-Burst-Completion Delta Time [RFC6332] 
16 Number of Duplicate Packets [RFC6332] 
17 Size of Burst-to-Multicast Gap [RFC6332] 
18-127 Unassigned Specification Required 
128-254 Reserved for private extensions [RFC6332] 
255 Reserved [RFC6332] 
The Type values 0 and 255 are reserved for future use. The Type 


values between (and including) 128 and 254 are reserved for private 
extensions. 


Any registration for an unassigned Type value needs to contain the 
following information: 


o Contact information of the one doing the registration, including 
at least name, address, and email. 


o A detailed description of what the new TLV element represents and 
how it is interpreted. 


Multicast Acquisition Status Code Space Registry 


A new IANA TLV space registry for the status codes has been created. 
The registry is called the "Multicast Acquisition Status Code Space 
Registry". This registry is to be managed by the IANA according to 
the Specification Required policy of [RFC5226]. 


The length of the Status field is two octets, allowing 65536 codes. 
However, the status codes have been registered to allow for an easier 
classification. For example, the values between (and including) 1 
and 1000 are primarily used by the MA method of simple join. The 
values between (and including) 1001 and 2000 are used by the MA 
method described in [RFC6285]. When registering new status codes for 
the existing MA methods or newly defined MA methods, registrants are 
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encouraged to allocate sufficient continuous space. Note that 
because of the limited space, not every MA method can be assigned 
1000 different values for its status codes. 


The status code 65535 is reserved for future use. The registry is 
initialized with the following entries: 


Code Description Reference 
0 A private status code is included in the message [RFC6332] 
1 Multicast join was successful [RFC6332] 
2 Multicast join has failed [RFC6332] 
3 A presentation error has occurred [RFC6332] 
4 An unspecified RTP receiver internal error has 

occurred [RFC6332] 
5-1000 Unassigned 
1001 RAMS has been successfully completed [RFC6332] 
1002 No RAMS-R message has been sent [RFC6332] 
1003 Invalid RAMS-I message syntax [RFC6332] 
1004 RAMS-I message has timed out [RFC6332] 
1005 RAMS unicast burst has timed out [RFC6332] 
1006 An unspecified RTP receiver internal error has 

occurred during RAMS [RFC6332] 
1007 A presentation error has occurred during RAMS [RFC6332] 
1008-65534 Unassigned 
65535 Reserved [RFC6332] 


Any registration for an unassigned status code needs to contain the 
following information: 


o Contact information of the one doing the registration, including 
at least name, address, and email. 


o A detailed description of what the new status code describes and 
how it is interpreted. 
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